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Advanced  polymorphic  type  systems  have  come  to  play  an  important  role 
in  the  world  of  functional  programming.  But,  so  far,  these  type  systems 
have  had  little  impact  upon  widely-used  imperative  programming  lan¬ 
guages  like  C  and  C++.  We  show  that  ML-style  polymorphism  can  be 
integrated  smoothly  into  a  dialect  of  C,  which  we  call  Polymorphic  C.  It 
has  the  same  pointer  operations  as  C,  including  the  address-of  operator 
&,  the  dereferencing  operator  *.  and  pointer  arithmetic.  We  give  a  natural 
semantics  for  Polymorphic  C,  and  prove  a  type  soundness  theorem  that 
gives  a  rigorous  and  useful  characterization  of  what  can  go  wrong  when  a 
well-typed  Polymorphic  C  program  is  executed.  For  example,  a  well-typed 
Polymorphic  C  program  may  fail  to  terminate,  or  it  may  abort  due  to  a 
dangling  pointer  error.  Proving  such  a  type  soundness  theorem  requires  a 
notion  of  an  attempted  program  execution;  we  show  that  a  natural  seman¬ 
tics  gives  rise  quite  naturally  to  a  transition  semantics,  which  we  call  a 
natural  transition  semantics,  that  models  program  execution  in  terms  of 
transformations  of  partial  derivation  trees.  This  technique  should  be  gen¬ 
erally  useful  in  proving  type  soundness  theorems  for  languages  defined 
using  natural  semantics. 


1  Introduction 


Much  attention  has  been  given  to  developing  sound  polymorphic  type  systems 
for  languages  with  imperative  features.  Most  notable  is  the  large  body  of 
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work  surrounding  ML  [4,21,14,5,11,24,22,19].  However,  none  of  these  efforts 
addresses  the  polymorphic  typing  of  a  language  that  combines  variables,  arrays 
and  pointers  (first-class  references),  which  are  key  ingredients  of  traditional 
imperative  languages.  As  a  result,  they  cannot  be  directly  applied  to  get  ML- 
style  polymorphic  extensions  of  widely-used  languages  like  C  and  C++. 

This  paper  presents  a  provably-sound  type  system  for  a  polymorphic  dialect  of 
C,  called  Polymorphic  C.  It  has  the  same  pointer  operations  as  C,  including 
the  address-of  operator  &,  the  dereferencing  operator  *,  and  pointer  arith¬ 
metic.  The  type  system  allows  these  operations  without  any  restrictions  on 
them  so  that  programmers  can  enjoy  C’s  pointer  flexibility  and  yet  have  type 
security  and  polymorphism  as  in  ML.  Also,  although  we  do  not  address  it 
here,  it  is  straightforward  to  do  type  inference  for  Polymorphic  C,  so  that 
programs  need  not  be  written  with  type  annotations  [16].  Our  type  system 
thus  demonstrates  that  ML-style  polymorphism  can  be  brought  cleanly  into 
the  realm  of  traditional  imperative  languages. 

We  establish  the  soundness  of  our  type  system  with  respect  to  a  natural  se¬ 
mantics  for  Polymorphic  C.  First  we  use  Harper’s  syntactic  approach  [8]  to 
establish  the  type  preservation  property  (also  known  as  the  subject  reduction 
property).  We  then  prove  a  type  soundness  theorem  that  gives  a  rigorous  and 
useful  characterization  of  what  can  go  wrong  when  a  well-typed  Polymorphic 
C  program  is  executed.  More  precisely,  we  show  that  the  execution  of  a  well- 
typed  Polymorphic  C  program  either  succeeds,  fails  to  terminate,  or  aborts 
due  to  one  of  a  specific  set  of  errors,  such  as  an  attempt  to  dereference  a 
dangling  pointer.  Proving  such  a  type  soundness  theorem  requires  a  notion  of 
an  attempted  program  execution ;  we  show  that  a  natural  semantics  gives  rise 
quite  naturally  to  a  transition  semantics,  which  we  call  a  natural  transition 
semantics ,  that  models  program  execution  in  terms  of  transformations  of  par¬ 
tial  derivation  trees.  This  technique  should  be  generally  useful  in  proving  type 
soundness  theorems  for  languages  defined  using  natural  semantics. 

We  begin  with  an  overview  of  Polymorphic  C  in  the  next  section.  Next,  Sec¬ 
tion  3  formally  defines  its  syntax,  type  system,  and  semantics.  Then,  in  Sec¬ 
tions  4  and  5,  we  prove  the  soundness  of  the  type  system.  We  conclude  with 
some  discussion. 


2  An  Overview  of  Polymorphic  C 


Polymorphic  C  is  intended  to  be  as  close  to  the  core  of  Kernighan  and  Ritchie 
C  [12]  as  possible.  In  particular,  it  is  stack-based  with  variables,  pointers,  and 
arrays.  Pointers  are  dereferenced  explicitly  using  *.  while  variables  are  derefer¬ 
enced  implicitly.  Furthermore,  pointers  are  first-class  values,  but  variables  are 
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not.  Polymorphic  C  has  the  same  pointer  operations  as  C.  A  well-typed  Poly¬ 
morphic  C  program  may  still  suffer  from  dangling  reference  and  illegal  address 
errors — our  focus  has  not  been  on  eliminating  such  pointer  insecurities,  which 
would  require  weakening  C’s  expressive  power,  but  rather  on  adding  ML-style 
polymorphism  to  C,  so  that  programmers  can  write  polymorphic  functions 
naturally  and  soundly  as  they  would  in  ML,  rather  than  by  parameterizing 
functions  on  data  sizes  or  by  casting  to  pointers  of  type  void  *. 


2.1  An  Example 


In  this  paper,  we  adopt  a  concrete  syntax  for  Polymorphic  C  that  resembles 
the  syntax  of  C. 1  For  example,  here  are  three  Polymorphic  C  functions: 

swap(x,y) 

{ 

var  t  =  *x; 


*x  =  *y; 

*y  =  t 

} 

reverse (a ,n) 

{ 

var  i  =  0; 

while  (i  <  n-l-i)  { 

swap(a+i,  a+n-l-i) ; 
i  =  i+1 

} 

} 

swapsections (a, i ,n) 

{ 

reverse (a , i) ; 
reverse (a+i ,n-i) ; 
reverse (a,n) 

} 

Note  that,  unlike  C,  Polymorphic  C  does  not  include  type  annotations  in  dec¬ 
larations.  (Also,  Polymorphic  C  differs  from  C  in  the  treatment  of  semicolons.) 
Function  reverse(a,n)  reverses  the  elements  of  array  a[0:n-l] ,  and  function 
swapsections  (a ,  i  ,n)  uses  reverse  to  swap  the  array  sections  a [0 :  i— 1]  and 

1  See  [20]  for  a  alternative  ML-like  syntax  that  is  somewhat  more  flexible. 
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a[i:n-l],  This  illustrates  that  in  Polymorphic  C,  as  in  C,  one  can  manipu¬ 
late  sections  of  arrays  using  pointer  arithmetic.  The  construct  var  x  =  e\\  e2 
binds  x  to  a  new  cell  initialized  to  the  value  of  e\\  the  scope  of  the  binding  is 
(-'•)  and  the  lifetime  of  the  cell  ends  after  e2  is  evaluated.  Variable  x  is  derefer¬ 
enced  implicitly.  This  is  achieved  via  a  typing  rule  that  says  that  if  e  has  type 
r  var ,  then  it  also  has  type  r. 

As  in  C,  the  call  to  swap  in  reverse  could  equivalently  be  written  as 

swap(&a[i]  ,  &a[n-l-i]) 


and  also  as  in  C,  array  subscripting  is  syntactic  sugar:  e\  [e2]  is  equivalent 
to  *(ei+e2).  Arrays  themselves  are  created  by  the  construct  arr  x[_e{\  ;  e2, 
which  binds  x  to  a  pointer  to  an  uninitialized  array  whose  size  is  the  value  of 
ei;  the  scope  of  x  is  e2,  and  the  lifetime  of  the  array  ends  after  e2  is  evaluated. 

The  type  system  of  Polymorphic  C  assigns  types  of  the  form  r  var  to  vari¬ 
ables,  and  types  of  the  form  r  ptr  to  pointers.  2  Functions  swap,  reverse,  and 
swapsections  given  above  are  polymorphic;  swap  has  type 

Ma  .  a  ptr  x  a  ptr  -+  a, 


reverse  has  type 


Vet .  a  ptr  x  int  -+  unit , 


and  swapsections  has  type 

Vet .  ct  ptr  x  int  x  int  -+  unit. 


Type  unit ,  which  appears  in  the  types  of  reverse  and  swapsections,  is  a 
degenerate  type  containing  only  the  value  unit;  it  serves  as  the  type  of  con¬ 
structs,  like  while  loops,  that  do  not  produce  a  useful  value.  Notice  that  pointer 
and  array  types  are  unified  as  in  C.  Also,  variable  and  pointer  types  are  related 
by  symmetric  typing  rules  for  &  and  *: 

if  e  :  r  var ,  then  &e  :  r  ptr , 

and 

if  e  :  t  ptr ,  then  *e  :  t  var. 

2  We  use  ptr  rather  than  ref  to  avoid  confusion  with  C++  and  ML  references. 
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Note  that  dereferencing  in  Polymorphic  C  differs  from  dereferencing  in  Stan¬ 
dard  ML,  where  if  e  :  r  re/,  then  !e  :  r. 

Polymorphic  C’s  types  are  stratified  into  three  levels.  There  are  the  ordinary 
t  (data  types)  and  a  (type  schemes)  type  levels  of  Damas  and  Milner’s  system 
[2],  and  a  new  level  called  phrase  types — the  terminology  is  due  to  Reynolds 
[17] — containing  a  types  and  variable  types  of  the  form  r  var.  This  stratifi¬ 
cation  enforces  the  “second-class”  status  of  variables:  for  example,  the  return 
type  of  a  function  must  be  a  data  type,  so  that  one  cannot  write  a  function 
that  returns  a  variable.  In  contrast,  pointer  types  are  included  among  the  data 
types,  making  pointers  first-class  values. 


2.2  Achieving  Type  Soundness  in  Polymorphic  C 


Much  effort  has  been  spent  trying  to  develop  sound  polymorphic  type  systems 
for  imperative  extensions  of  core-ML.  Especially  well-studied  is  the  problem 
of  typing  Standard  ML’s  first-class  references  [21,14,5,11,24],  The  problem  is 
easier  in  a  language  with  variables  but  no  references,  such  as  Edinburgh  LCF 
ML,  but  subtle  problems  still  arise  [4],  The  key  problem  is  that  a  variable  can 
escape  its  scope  via  a  lambda  abstraction  as  in 

letvar  stk  :=  []  in  Xv.stk  :=  v  ::  stk 

(This  evaluates  to  a  push  function  that  pushes  values  v  onto  a  stack,  imple¬ 
mented  as  a  list:  here  []  denotes  the  empty  list  and  ::  denotes  cons.)  In  this 
case,  the  type  system  must  not  allow  type  variables  that  occur  in  the  type  of 
stk  to  be  generalized,  or  else  the  list  would  not  be  kept  homogeneous.  Different 
mechanisms  have  been  proposed  for  dealing  with  this  problem  [4,22,19] 

In  the  context  of  Polymorphic  C,  however,  we  can  adopt  an  especially  simple 
approach.  Because  Polymorphic  C  does  not  have  first-class  functions,  it  is  not 
possible  to  compute  a  polymorphic  value  in  an  interesting  way;  for  example, 
we  cannot  write  curried  functions.  For  this  reason,  we  suffer  essentially  no  loss 
of  language  expressiveness  by  limiting  polymorphism  to  function  declarations. 

Limiting  polymorphism  to  function  declarations  ensures  the  soundness  of  poly¬ 
morphic  generalizations,  but  pointers  present  new  problems  for  type  sound¬ 
ness.  If  one  is  not  careful  in  formulating  the  semantics,  then  the  type  preserva¬ 
tion  property  may  not  hold.  For  example,  if  a  program  is  allowed  to  dereference 
a  pointer  to  a  cell  that  has  been  deallocated  and  then  reallocated,  then  the 
value  obtained  may  have  the  wrong  type.  For  this  reason,  our  natural  seman¬ 
tics  has  been  designed  to  catch  all  pointer  errors. 
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3  A  Formal  Description  of  Polymorphic  C 


The  syntax  of  Polymorphic  C  is  given  by  the  following  grammar: 

e  |  c  |  fee  |  *  e  |  61+62  | 

6-i  [eg]  |  ei  =  e2  |  ( 1 ;  62  | 
if  (ex)  {e2}  else  {e3}  | 
while  (ei )  {e2}  | 
var  x  =  ei ;  e,2  \ 
arr  xle1']  ;  e2  | 
x(xi,. . .  ,xn)  {ei}  e2  | 

6 (61 ,  ...  ,  6n ) 


Meta-variable  r  ranges  over  identifiers,  and  c  over  literals  (such  as  integer 
literals  and  unit).  The  expression 

x(xi ,. . .  ,xn)  {ei}  e2 


is  a  function  declaration;  it  declares  a  function  x  whose  scope  is  62-  The  + 
operator  here  denotes  only  pointer  arithmetic.  In  the  full  language,  +  would 
be  overloaded  to  denote  integer  addition  as  well. 

Like  C,  Polymorphic  C  has  been  designed  to  ensure  that  function  calls  can 
be  implemented  on  a  stack  without  the  use  of  static  links  or  displays.  In  C, 
this  property  is  achieved  by  the  restriction  that  functions  can  only  be  defined 
at  top  level.  Since  Polymorphic  C  allows  function  declarations  anywhere,  we 
instead  impose  the  restriction  that  the  free  identifiers  of  any  function  must  be 
declared  at  top  level.  Roughly  speaking,  a  top-level  declaration  is  one  whose 
scope  extends  all  the  way  to  the  end  of  the  program.  For  example,  in  the 
program 

var  n  =  . . . ; 

arr  a[. . .]  ; 

<w  {•••} 

the  identifiers  declared  at  top  level  are  n,  a,  and  f .  So  the  only  identifiers  that 
can  occur  free  in  f  are  n  and  a. 
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A  subtle  difference  between  C  and  Polymorphic  C  is  that  the  formal  param¬ 
eters  of  a  Polymorphic  C  function  are  constants  rather  than  local  variables. 
Hence  the  C  function  f  (x)  {b}  is  equivalent  to 


f(x)  {var  x  =  x;  b} 

in  Polymorphic  C.  Also,  Polymorphic  C  cannot  directly  express  C’s  internal 
static  variables.  For  example,  the  C  declaration 

f(x)  {static  int  n  =  0;  b} 

must  be  written  in  Polymorphic  C  as 

var  n  =  0;  f(x)  {b} 

where  n  has  been  uniquely  renamed. 


3. 1  The  Type  System  of  Polymorphic  C 


The  types  of  Polymorphic  C  are  stratified  as  follows. 


T 

::=  a  \ 

int 

unit  t  ptr  T\  x  •  ■ 

x  Tn  — y  t  ( data  types ) 

O 

::=  Va . 

0 

T 

( type  schemes) 

P 

::=  0 

r  var 

(phrase  types ) 

Meta-variable  a  ranges  over  type  variables.  Compared  to  the  type  system  of 
Standard  ML  [15],  all  type  variables  in  Polymorphic  C  are  imperative. 

The  rules  of  the  type  system  are  given  in  Figures  1  and  2.  It  is  a  deductive 
proof  system  used  to  assign  types  to  expressions.  Typing  judgments  have  the 
form 


7  h  e  :  p 


meaning  that  expression  e  has  type  p.  assuming  that  7  prescribes  phrase  types 
for  the  free  identifiers  of  e.  More  precisely,  metavariable  7  ranges  over  identifier 
typings ,  which  are  finite  functions  mapping  identifiers  to  phrase  types;  j(x)  is 
the  phrase  type  assigned  to  x  by  7  and  7 [sc  :  p]  is  a  modified  identifier  typing 
that  assigns  phrase  type  p  to  x  and  assigns  phrase  type  x ')  to  any  identifier 
x'  other  than  x. 
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(ident)  7  b  x  :  t  if  j(x)  >  r 

(var-id)  7  h  x  :  t  var  if  7(2;)  =  r  var 

(lit)  7  b  c  :  int  if  c  is  an  integer  literal 

7  b  unit  :  unit 

(r-val)  7  b  e  :  t  var 

7  b  e  :  r 

(address)  7  b  e  :  r  war 
7  b  &e  :  r  ptr 

(l-val)  7  b  e  :  r  ptr 

7  b  *e  :  r  var 

(arith)  7  b  ei  :  t  ptr ,  7  b  62  :  int 


(subscript) 

7  b  ei+e2  :  r  ptr 

7  b  ei  :  r  ptr,  7  b  e2  :  int 

(assign) 

7  b  ei [e2]  :  r  var 

7  b  ei  :  r  war,  7  b  e2  :  r 

(compose) 

7  b  ei=e2  :  r 

7  b  e\  :  ri ,  7  b  e2  :  r2 

(IF) 

7  b  ei ;  e2  :  t2 

7  b  ei  :  int ,  7  b  e2  :  r,  7  b  e3  :  r 

(while) 

7  b  if  (ei)  {e2}  else  {e3}  :  r 

7  b  e-i  :  int ,  7  b  e2  :  r 

(let  var) 

7  b  while  (ei)  {e2}  :  unit 

7  b  ei  :  ri,  7'[t  :  war]  b  e2  :  r2 

Fig.  1 

7  b  var  t  =  e\ ;  e2  :  r2 

.  Rules  of  the  Type  System  (Part  1) 
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7  b  e\  :  int ,  7 [re  :  ly  ptr]  b  e2  :  r2 
7  b  arr  x  [r  1  ]  ;  e2  :  r2 

7^1  :  vi, . .  .,xn  :  rn\  b  e  :  r 
7 [re  :  C7ose7(ri  x  •  •  •  x  r„  -)  r)]  b  e7  :  t' 

7  b  rr  (.X|  , . .  {e}  e'  :  r7 

7  b  e  :  n  x  •  •  •  x  rn  -A  f , 

7  b  %  :  Ti, 

7  b  en  .  Tn 

7  b  e(ei , . . . ,e„)  :  r 

Fig.  2.  Rules  of  the  Type  System  (Part  2) 

The  generalization  of  a  data  type  r  relative  to  7,  written  C7ose7(r),  is  the 
type  scheme  Ma .  r,  where  a  is  the  set  of  all  type  variables  occurring  free  in  r 
but  not  in  7.  Note  the  use  of  Close  in  rule  (fun);  this  is  what  allows  functions 
to  be  given  polymorphic  types. 

We  say  that  t'  is  a  generic  instance  of  Ma  .  r,  written  Vq  .  r  >  r7,  if  there  exists 
a  substitution  S  with  domain  a  such  that  St  =  t' .  Note  that  rule  (ident) 
allows  an  identifier  x  to  be  given  any  type  r  that  is  a  generic  instance  of  7(2;); 
this  is  what  allows  a  polymorphic  function  to  be  called  with  different  types 
of  arguments.  We  extend  the  definition  of  >  to  type  schemes  by  saying  that 
a  >  a'  if  a  >  r  whenever  a'  >  t.  Finally,  we  say  that  7  b  e  :  a  if  7  b  e  :  r 
whenever  a  >  t. 


(letarr) 


(fun) 


(funcall) 


3.2  The  Semantics  of  Polymorphic  C 


We  now  give  a  natural  semantics  for  Polymorphic  C.  Before  we  can  do  this,  we 
need  to  extend  the  language  syntax  to  include  some  semantic  values;  these  new 
values  are  the  runtime  representations  of  variables,  pointers,  and  functions: 

e  ::=  (a,  1)  |  (a,  0)  |  A./7. . r„.  c 


Metavariable  a  here  ranges  over  addresses,  which  are  described  below.  Expres¬ 
sion  (a,  1)  is  a  variable  and  expression  (a,  0)  is  a  pointer.  Intuitively,  a  variable 
or  pointer  is  represented  by  an  address  together  with  a  tag  bit,  which  tells 
whether  it  should  be  implicitly  dereferenced  or  not — thus,  variables  are  im¬ 
plicitly  dereferenced  and  pointers  are  not.  Expression  A./\] , . . . ,  xn.  e  is  a  lambda 
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abstraction  that  represents  a  function  with  formal  parameters  Xi, ... ,  xn  and 
body  e. 

One  might  expect  that  addresses  would  just  be  natural  numbers,  but  that 
would  not  allow  the  semantics  to  detect  invalid  pointer  arithmetic.  So  instead 
an  address  is  a  pair  of  natural  numbers  (/,  j)  where  i  is  the  segment  number 
and  j  is  the  offset.  Intuitively,  we  put  each  variable  or  array  into  its  own 
segment.  Thus  a  simple  variable  has  address  (?',0),  and  an  //-element  array 
has  addresses  (?',  0),  (/,  1), . . . ,  (?',  n  —  1).  Pointer  arithmetic  involves  only  the 
offset  of  an  address,  and  dereferencing  nonexistent  or  dangling  pointers  is 
detected  as  a  “segmentation  fault”. 

Next  we  identify  the  set  of  values  v,  consisting  of  literals,  pointers,  and  lambda 
abstractions: 


v  ::=  c  |  (a,  0)  |  A.r i . .  < 


The  result  of  a  successful  evaluation  is  always  a  value. 

Finally,  we  require  the  notion  of  a  memory.  A  memory  //  is  a  finite  function 
mapping  addresses  to  values,  or  to  the  special  results  dead  and  uninit.  These 
results  indicate  that  the  cell  with  that  address  has  been  deallocated  or  is  unini¬ 
tialized,  respectively.  We  write  fi(a)  for  the  contents  of  address  a  G  dom(/i), 
and  we  write  fi[a  :=  v\  for  the  memory  that  assigns  value  v  to  address  a,  and 
value  n(a')  to  any  address  a'  other  than  a.  Note  that  fi[a  :=  v]  is  an  update  of 
//  if  a  G  dom(p)  and  an  extension  of  //  if  a  dom(n). 

We  can  now  define  the  evaluation  relation 

H  N  -e  =>  v,  ji 


which  asserts  that  evaluating  closed  expression  e  in  memory  //  results  in  value 
v  and  new  memory  fi' .  The  evaluation  rules  are  given  in  Figures  3  and  4. 

We  write  [e' /x\e  to  denote  the  capture-avoiding  substitution  of  e'  for  all 
free  occurrences  of  x  in  e.  Note  the  use  of  substitution  in  rules  (bindvar), 
(bindarr),  (bindfun),  and  (apply).  It  allows  us  to  avoid  environments  and 
closures  in  the  semantics,  so  that  the  result  of  evaluating  a  Polymorphic  C 
expression  is  just  another  Polymorphic  C  expression.  This  is  made  possible  by 
the  flexible  syntax  of  the  language  and  the  fact  that  only  closed  expressions 
are  ever  evaluated  during  the  evaluation  of  a  closed  expression. 

We  remark  that  rule  (apply)  specifies  that  function  arguments  are  evaluated 
left  to  right;  C  leaves  the  evaluation  order  unspecified.  Also,  note  that  if  there 
were  no  &  operator,  there  would  be  no  need  to  specify  in  rule  (bindvar)  that 
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(val) 

(contents) 


(deref) 


(ref) 


(offset) 


(update) 


(sequence) 


(branch) 


H  b  v  =>  v ,  fi 

a  G  dom(n)  and  yu(a)  is  a  value 
H  b  (a,  1)  =>  ^i(a),  fi 

H  b  e  =>  (a,  0),  /j,' 
a  G  dom(n')  and  ///(a)  is  a  value 

//,  b  *e  =>•  ^'(a),  /// 

H  b  &(a,  1)  =>■  (a,  0),  /r 

//  be=>  (a,  0),  //' 

H  b  &*e  =>  (a,  0),  /// 

b  ei  =>  ((*,  j),0),//i 
Au  b  62  =>•  n,  fi'  (n  an  integer) 

H  b  ei+e2  =>■  ((/../  +  n),  0),  fi' 
fx  b  e  =>  u,  /// 

a  G  dom(fi')  and  yu'(a)  ^  dead 
//  b  (a,  l)=e  =>■  u,  /i'[a  :=  u] 

//  b  ei  =>  (a,  0),  at 
AT  b  e2  =>  w,  AT 

a  G  dom(/r2)  and  //2  ( a )  ^  dead 
fx  b  *ei=e2  =>■  v,  fi2[a  :=  u] 

//  b  e.i  >  ('j .  //| 

/U  b  e2  =>  u2,  //2 

/<  b  ei ;  e2  =>  u2,  //2 

//,  b  ei  =>  n,  //i  (n  a  nonzero  integer) 
AT  b  e2  =>  v,  fi' 

fi  b  if  (ei)  {e2}  else  {e3}  >  t\ // 


/Li  b  ei  =>•  0,  //,  i 
AH  b  e3  =>■  u,  fi' 

fi  b  if  (ei)  {e2}  else  {e3}=>u,Ai' 
Fig.  3.  The  Evaluation  Rules  (Part  1) 
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(loop)  //  (?|  >  0.  // 1 

//,  h  while  (ei)  {62}  =4>  unit,  // 1 

H  b  ei  =>•  n,  // 1  (n  a  nonzero  integer) 

H 1  I-  e2  =>  t>,  ^2 

//,2  I-  while  (ei)  {e2}  =4>  unit.  //,' 

//,  h  while  (ei)  {e2}  =4>  unit,  /// 

(bindvar)  h  \-  e1  =4>  t>i, 

(?', 0)  dom(ni) 

l<\ .{ '■  0)  :=  ui]  h  [((«,  0),  l)/rc]e2  =>  w2,^2 
//,  h  var  x  =  ei ;  e2  =4>  i)2,  /r2[(«,  0)  :=  dead] 

(bindarr)  //,  h  ei  =>•  n,  // 1  (n  a  positive  integer) 

(i,0)  ^  dom(fi± ) 

0), . . . ,  (?',  n  —  1)  :=  uninit, . . . ,  uninit]  h 

[((*,  0),  0)/x]e2  =>  f2,^2 

//.  h  arr  x  [ei]  ;  e2  => 

x2,  ^[(b  0), . . . ,  (*,  n  -  1)  :=  dead, . . . ,  dead] 

(bindfun)  1^1  h  [Axi, . . . ,  xn.  e/x\e'  =4>  x, 

/1  h  x  (x’i ,xn)  {e}  e'  =>•  «,  //,' 

(apply)  h  h  e  =>  Axi, . . . ,  xn.  e' ,  n 1 

AT  1“  ei  =4>  xi,  //2 

hn  ATi+1 

Abi+1  I"  [«1,  •  •  •  ,  Wn/^1,  •  •  •  ,  ^n]e'  =>  X, 

//  r  (r  1 ,  ...  ,e„)  =4>  x,  //' 

Fig.  4.  The  Evaluation  Rules  (Part  2) 

a  variable  dies  at  the  end  of  its  scope;  it  would  simply  become  unreachable  at 
that  point  (and  its  storage  could  be  reused). 

Note  that  a  successful  evaluation  always  produces  a  value  and  a  memory: 
Lemma  1  If  n  b  e  =>  x,  ///,  then  v  is  a  value  and  ///  is  a  memory. 

PROOF.  By  induction  on  the  structure  of  the  derivation.  □ 
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4  Type  Preservation 


We  now  turn  to  the  question  of  the  soundness  of  our  type  system.  We  begin 
in  this  section  by  using  the  framework  of  Harper  [8]  to  prove  that  our  type 
system  satisfies  the  type  preservation  property  (sometimes  called  the  subject 
reduction  property).  This  property  basically  asserts  that  types  are  preserved 
across  evaluations;  that  is,  if  an  expression  of  type  r  evaluates  successfully,  it 
produces  a  value  of  type  r.  But  before  we  can  do  this,  we  need  to  extend  our 
typing  rules  so  that  we  can  type  the  semantic  values  (variables,  pointers,  and 
lambda  abstractions)  introduced  in  Section  3.2. 

Typing  a  variable  («,  1)  or  a  pointer  (a,  0)  clearly  requires  information  about 
the  type  of  value  stored  at  address  a;  this  information  is  provided  by  an 
address  typing  A.  One  might  expect  an  address  typing  to  map  addresses  to  data 
types.  This  turns  out  not  to  work,  however,  because  a  well-typed  program  can 
produce  as  its  value  a  nonexistent  pointer,  and  such  pointers  must  therefore 
be  typable  if  type  preservation  is  to  hold.  For  example,  the  program 

arr  a [10] ;  a+17 

is  well  typed  and  evaluates  to  ((0, 17),  0),  a  nonexistent  pointer.  This  leads  us 
to  define  an  address  typing  A  to  be  a  finite  function  mapping  segment  numbers 
to  data  types.  The  notational  conventions  for  address  typings  are  like  those 
for  identifier  typings. 

We  now  modify  our  typing  judgments  to  include  an  address  typing: 


A;  7  b  e  :  p 


All  of  the  rules  given  previously  in  Figures  1  and  2  need  to  be  extended 
to  include  address  typings,  and  we  also  add  the  new  typing  rules  given  in 
Figure  5.  Furthermore,  Figure  5  includes  an  updated  version  of  rule  (fun) 
from  Figure  2.  In  addition  to  including  an  address  typing  A,  the  new  rule 
replaces  Close1  with  Close \rr  which  does  not  generalize  type  variables  that 
are  free  in  either  A  or  in  7. 

To  prove  the  type  preservation  theorem,  we  require  a  number  of  lemmas  that 
establish  some  useful  properties  of  the  type  system.  We  begin  with  a  basic 
lemma  that  shows  that  our  type  system  types  closed  values  reasonably — it 
shows  that  any  closed  value  of  some  type  has  the  form  that  one  would  expect. 
It  also  shows  that  a  closed  expression  of  type  r  var  can  have  only  two  possible 
forms.  (Note  that  0  here  denotes  an  empty  identifier  typing.) 
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(var) 

A;  7  I"  ((bj),l) 

:  r 

var  if  A (i)  =  r 

(ptr) 

A;  7  b  ((*,  j),0) 

:  r 

ptr  if  X(i)  =  t 

( — >■- intro) 

A;  7 [i|i  :  ri, . . . , 

xn 

:  Tn\  b  e  :  r 

A;  7  b  Axi, 

xn- 

e  :  ri  x  •  •  •  x  rn  — >■  r 

(fun) 

A;  7[.Ti  :  , . . . , 

xn 

■  rn  ]  b  e  :  t 

A;  j[x  :  Close\.y(ri 

X 

X 

u 

T 

A;  7  b  x(x  1 , . . . 

>  %n 

)  {e}  e'  :  r' 

Fig.  5.  New  Rules  for  Typing  Semantic  Values 
Lemma  2  (Correct  Forms)  Suppose  A;  0  b  v  :  r.  Then 

-  if  t  is  int,  then  v  is  an  integer  literal, 

-  if  t  is  unit,  then  v  is  unit. 

-  if  r  is  t'  ptr,  then  v  is  of  the  form  0),  and 

-  if  t  is  ri  x  •  •  •  x  tn  — >■  r' ,  then  v  is  of  the  form  Aaq, . . . ,  xn.e. 

And  if  A;  0  b  e  :  r  var,  then  e  is  of  the  form  ((?',  j),  1)  or  of  the  form  *e' . 


PROOF.  Immediate  from  inspection  of  the  typing  rules.  (Note  that  the  last 
part  of  the  lemma  assumes  that  array  subscripting  is  syntactic  sugar. )  □ 


A  consequence  of  the  last  part  of  this  lemma  is  that  if  A;  0  b  e  :  t  and  e  is  not 
of  the  form  ((i,j),  1)  or  *e;,  then  the  typing  derivation  cannot  end  with  rule 
(r-VAl).  So  the  typing  rules,  for  the  most  part,  remain  syntax  directed. 

The  fact  that  variables  can  have  only  two  possible  forms  is  also  exploited  in 
our  evaluation  rules,  specifically  within  rules  (ref)  and  (update)  of  Figure  3. 
In  particular,  we  are  able  to  define  the  semantics  of  =  and  &  without  defining 
an  auxiliary  relation  for  evaluation  in  “L-value”  contexts;  contrast  our  rules 
with  those  given  in  [3]. 

We  continue  with  some  basic  lemmas  showing  that  typings  are  preserved  under 
substitutions  and  under  extensions  to  the  address  and  identifier  typings: 

Lemma  3  (Type  Substitution)  If  A;  7  b  e  :  r,  then  for  any  substitution 
S ,  S A;  £>7  b  e  :  St,  and  the  latter  typing  has  a  derivation  no  higher  than  the 
former. 


PROOF.  By  induction  on  the  structure  of  the  derivation  of  A;  7  b  e  :  r.  □ 
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Lemma  4  (Superfluousness)  Suppose  that  A;  7  b  e  :  r.  If  i  ^  dom(X),  then 
A[*  :  r7]  j.7  b  e  :  77  and  if  x  dom( 7),  t/ien  A;  7  [a;  :  p]  b  e  :  t. 


PROOF.  By  induction  on  the  height  of  the  derivation  of  A;  7  b  e  :  r.  The 
only  way  that  adding  an  extra  assumption  can  cause  problems  is  by  adding 
more  free  type  variables  to  A  or  7,  thereby  preventing  Close  from  generalizing 
such  variables  in  (fun)  steps.  If  this  happens,  we  must  rename  such  variables 
in  the  original  derivation  before  adding  the  extra  assumption.  By  the  Type 
Substitution  Lemma,  we  can  do  this  renaming  and  the  height  of  the  derivation 
is  not  increased.  □ 


Lemma  5  (Substitution)  If  A;  7  b  e  :  p  and  A;  7 [a;  :  p]  b  e!  :  r,  then 
A;  7  b  [e/x\e'  :  r. 


PROOF.  Assume  that  the  bound  identifiers  of  e'  are  renamed  as  necessary 
to  ensure  that  no  identifier  occurring  in  e  occurs  bound  in  e' .  Then  at  every 
use  of  (ident)  or  (var-id)  on  x  in  the  derivation  of  A;  7 [rr  :  p]  b  e'  :  r,  we  can 
splice  in  the  appropriate  derivation  for  e.  There  may  be  extra  assumptions 
around  at  that  point,  but  by  the  Superfluousness  Lemma,  they  do  not  cause 
problems.  □ 


Lemma  6  (V-intro)  If  A;  7  b  e  :  r  mid  au, . . . ,  an  do  not  occur  free  in  A  or 
in  7,  then  A;  7  b  e  :  Vau, . . . ,  an  .  t. 


PROOF.  This  lemma  is  a  simple  corollary  to  the  Type  Substitution  Lemma. 
Suppose  that  Ma .  t  >  t' .  Then  there  exists  a  substitution  S  =  [f/a]  such  that 
St  =  t' .  By  the  Type  Substitution  Lemma,  S A;  £7  b  e  :  St.  Hence,  since  the 
a  are  not  free  in  A  or  in  7,  A;  7  b  e  :  r'.  □ 


We  now  return  to  type  preservation.  Roughly  speaking,  we  wish  to  show  that 
if  closed  program  e  has  type  r  under  address  typing  A,  and  evaluates  under 
memory  //,  to  v,  then  v  also  has  type  r.  But  since  e  can  allocate  addresses 
and  these  can  occur  in  v,  we  cannot  show  that  v  has  type  r  under  A — we  can 
only  show  that  v  has  type  r  under  some  address  typing  A7  that  extends  A.  (We 
denote  “A7  extends  A”  by  A  C  A7.)  Also,  we  need  to  assume  that  A  is  consistent 
with  p. — for  example,  if  A(?')  =  int ,  then  //  needs  to  store  integers  in  segment 
i.  Precisely,  we  define  //  :  A  if 

(i)  dom(X)  =  {/  |  (z,  0)  €  dom(p )},  and 
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(ii)  for  all  (?',  j)  such  that  //( !  j ) )  is  a  value,  A  b  /i((i,j))  :  X (i). 

Note  that  A  must  give  a  type  to  uninitialized  and  dead  addresses  of  //,,  but  the 
type  can  be  anything.  We  can  now  prove  the  type  preservation  theorem: 

Theorem  7  (Type  Preservation)  If  /i  X  e  =>  v,  ///,  A;  0  b  e  :  r,  and  //,  :  A, 
then  there  exists  X'  such  that  X  C  X' ,  fi'  :  X' ,  and  X';  0  b  v  :  r. 


PROOF.  By  induction  on  the  structure  of  the  derivation  of  //,  b  e  =y  v^i'. 
Here  we  just  show  the  (bindvar)  and  (bindfun)  cases;  the  remaining  cases 
are  similar. 

(bindvar).  The  evaluation  must  end  with 
H  b  e\  =>-  /'i .  // 1 

(*,  0)  0  dom(fii) 

0)  :=  ui]  b  [((«,  0),  l)/rc]e2  =>  «2,^2 

//  b  var  a:  =  ei ;  e2  =>-  eg,  //2[(a  0)  :=  dead] 

while  the  typing  must  end  with  (letvar): 

A;  0  b  ei  :  rx 

A;  :  ri  uar]  b  e2  :  r2 

A;  0  b  var  a:  =  ex\  e2  :  r2 


and  //  :  A.  By  induction,  there  exists  Ai  such  that  A  C  Aj,  ^ i  :  Ai,  and 
Ai;  0  b  ui  :  n.  Since  ii\  :  Ai  and  (z,  0)  ^  dom(ni),  also  i  fL  dom( Ai).  So 
Ai  C  A i  [i  :  n].  By  rule  (var), 

Ai [z  :  n];  0  b  ((i,  0),  1)  :  t\  var 


and  by  Lemma  4, 


Ai[*  :  Ti];  [: x  :  Ti  var]  b  e2  :  r2 


So  we  can  apply  Lemma  5  to  get 


Ai [/  :  ri];0  b  [((/,  0),l)/r]e2  :  r2 


Also,  yrzi [(z,  0)  :=  t>i]  :  Ai [z  :  Ti].  So  by  a  second  use  of  induction,  there  exists 
X'  such  that  A i  [i  :  n]  C  A',  /i2  :  A',  and  A';  0  b  r2  :  r2. 
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It  only  remains  to  show  that  ^2[(i,  0)  :=  dead]  :  A7.  But  this  follows  immedi¬ 
ately  from  //2  :  A7. 

Remark  8  What  would  go  wrong  if  we  simply  removed  the  deallocated  ad¬ 
dress  ( i ,  0)  from  the  domain  of  the  final  memory,  rather  than  marking  it  dead? 
Well,  with  the  current  definition  of  //  :  A,  we  would  then  be  forced  to  remove  i 
from  the  final  address  typing.  But  then  //2  —  i  :  A7  —  i  would  fail,  if  there  were 
any  dangling  pointers  ((?',  j),  0)  in  the  range  of  //2  —  i.  If,  instead,  we  allowed 
A7  to  retain  the  typing  for  i.  then  the  next  time  that  (i.  0)  were  allocated  we 
would  have  to  change  the  typing  for  i,  rather  than  extend  the  address  typing. 

(bindfun).  The  evaluation  must  end  with 

//  h  A./' i , . . . ,  xn.  e/x]e'  =>  v,  // 

//  h  x  (rci ,xn)  {e}  e7  =>  t> ,  /// 


while  the  typing  must  end  with  (fun): 

A;  [x1  :  ri, . . .  ,:rn  :  r„]  h  e  :  r 

A;  [at  :  Close\$(Ti  x  •  •  •  x  rn  — >■  r)]  h  e'  :  t7 

A;  0  h  rcCati , . . .  ,z„)  {e}  e'  :  r7 


and  g,  :  A.  By  rule  (— >■- intro), 

A;  0  h  A.ti,  . . . ,  xn.  e  :  ri  x  •  •  •  x  rn  — >■  r 

and  so  by  Lemma  6, 

A;  0  h  Aati, . . . ,  xn.  e  :  Closex-${ri  x  •  •  •  x  rn  — >■  r) 

Therefore,  by  Lemma  5,  A;  0  h  [Arci, . . .  ,.Fn.  e/x\e'  :  r7.  So  by  induction,  there 
exists  A7  such  that  A  C  A7,  ///  :  A7,  and  A7  h  d  :  r7.  □ 


5  Type  Soundness 


The  type  preservation  property  does  not  by  itself  ensure  that  a  type  system 
is  sensible.  For  example,  a  type  system  that  assigns  every  type  to  every  ex¬ 
pression  trivially  satisfies  the  type  preservation  property,  even  though  such  a 
type  system  is  useless.  The  main  limitation  of  type  preservation  is  that  it  only 
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applies  to  well-typed  expressions  that  evaluate  successfully.  Really  we  would 
like  to  be  able  to  say  something  about  what  happens  when  we  attempt  to 
evaluate  an  arbitrary  well-typed  expression. 

One  approach  to  strengthening  type  preservation  (used  by  Gunter  [6]  and 
Harper  [9],  for  example)  is  to  augment  the  natural  semantics  with  rules  spec¬ 
ifying  that  certain  expressions  evaluate  to  a  special  value,  TypeError,  which 
has  no  type.  For  example,  an  attempt  to  dereference  a  value  other  than  a 
pointer  would  evaluate  to  TypeError.  Then,  by  showing  that  type  preser¬ 
vation  holds  for  the  augmented  evaluation  rules,  we  get  that  a  well-typed 
expression  cannot  evaluate  to  TypeError.  Hence  any  of  the  errors  that  lead 
to  TypeError  cannot  occur  in  the  evaluation  of  a  well-typed  expression.  A 
drawback  to  this  approach  is  the  need  to  augment  the  natural  semantics.  But, 
more  seriously,  this  approach  does  not  give  us  as  much  information  as  we 
would  like.  It  tells  us  that  certain  errors  will  not  arise  during  the  evaluation 
of  well-typed  expression,  but  it  leaves  open  the  possibility  that  there  are  other 
errors  that  we  have  neglected  to  check  for  in  the  augmented  natural  semantics. 

Another  approach  is  to  use  a  different  form  of  semantics  than  natural  seman¬ 
tics.  This  is  the  approach  advocated  by  Wright  and  Felleisen  [25],  who  use 
a  small-step  structured  operational  semantics  to  prove  type  soundness  for  a 
number  of  extensions  of  ML.  However,  we  find  natural  semantics  to  be  much 
more  natural  and  appealing  than  small-step  structured  operational  semantics, 
particularly  for  languages  with  variables  that  have  bounded  lifetimes.  (For 
example,  in  Ozgen’s  proposed  small-step  semantics  for  Polymorphic  C  [16], 
quite  subtle  mechanisms  are  employed  to  deallocate  cells  at  the  correct  time. ) 
Gunter  and  Remy  [7]  also  propose  an  alternative  to  natural  semantics,  which 
they  call  partial  proof  semantics. 

What  we  propose  here  is  different.  We  argue  that  one  can  show  a  good  type 
soundness  theorem  for  a  language,  like  Polymorphic  C,  defined  using  natural 
semantics.  The  trouble  with  natural  semantics  is  that  it  defines  only  complete 
program  executions,  which  are  represented  by  derivation  trees.  But  for  a  good 
type  soundness  theorem,  we  need  a  notion  of  an  attempted  execution  of  a 
program,  which  may  of  course  fail  in  various  ways.  We  argue,  however,  that  a 
natural  semantics  gives  rise  in  a  natural  way  to  a  transition  semantics,  which 
we  call  a  natural  transition  semantics ,  that  provides  the  needed  notion  of  an 
attempted  program  execution.  3 

The  basic  idea  is  that  a  program  execution  is  a  sequence  of  partial  derivation 
trees ,  that  may  or  may  not  eventually  reach  a  complete  derivation  tree.  In  a 
partial  derivation  tree,  some  of  the  nodes  may  be  labeled  with  pending  judg¬ 
ments.  which  represent  expressions  that  need  to  be  evaluated  in  the  program 

3  See  [23]  for  a  slightly  different  formulation  of  natural  transition  semantics;  there, 
natural  transition  semantics  is  applied  to  a  problem  of  computer  security. 
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execution.  A  pending  judgment  is  of  the  form  //,  b  e  =>?.  (In  contrast,  we  refer 
to  ordinary  judgments  //  b  e  =>  u,  //,'  as  complete  judgments.) 

Before  we  define  partial  derivation  trees  precisely,  we  need  to  make  a  few 
comments  about  the  evaluation  rules  in  a  natural  semantics.  First,  note  that 
natural  semantics  rules  are  actually  rule  schemas,  whose  metavariables  are 
instantiated  in  any  use  of  the  rule.  Second,  note  that  the  hypotheses  of  each 
rule  are  either  evaluation  judgments  //  be=>  v,  p'  or  boolean  conditions,  such 
as  the  condition  a  €  dom(p)  in  rule  (contents).  (Such  boolean  conditions 
are  regarded  as  complete  judgements.)  Finally,  note  that  in  some  hypotheses 
an  evaluation  judgment  includes  an  implicit  boolean  condition.  For  example, 
the  first  hypothesis  of  rule  (deref)  is 

p  b  e  =>  (a,  0),  p' 


This  hypothesis  is  really  an  abbreviation  for  two  hypotheses: 

p  b  e  =>  v  ,  p! 


and 


v  is  of  the  form  (a,  0) 


Assume  henceforth  that  we  use  the  unabbreviated  forms  in  derivation  trees. 

We  want  partial  derivation  trees  to  be  limited  to  the  trees  that  can  arise  in 
a  systematic  attempt  to  build  a  complete  derivation  tree;  this  constrains  the 
form  that  such  a  tree  can  have.  Precisely, 

Definition  9  A  tree  T  whose  nodes  are  labeled  with  (partial  or  complete) 
judgments  is  a  partial  derivation  tree  if  it  satisfies  the  following  tivo  conditions: 

(i)  If  a  node  in  T  is  labeled  with  a  complete  judgment  J ,  then  the  subtree 
rooted  at  that  node  is  a  complete  derivation  tree  for  J. 

(li)  If  a  node  in  T  is  labeled  with  a  pending  judgment  p  b  e  =>?  and  the  node 
has  k  children,  ivhere  k  >  0,  then  there  is  an  instance  of  an  evaluation 
rule  that  has  the  form 


•I  \  ■!)  ...  Jn 
p,  b  e  =>  v  ,  p' 

where  n  >  k,  and  the  labels  on  the  children  are  Jp  J2, . . . ,  -4 ,  respectively, 
with  possibly  one  exception:  if  Jk  is  Pk  b  e&  =>  Vk,  p'k,  then  the  kth  child 
may  alternatively  be  labeled  with  the  pending  judgment  pk  4  ek  =>-?. 
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One  may  readily  see  that  a  partial  derivation  tree  can  have  at  most  one  pending 
judgment  on  each  level,  which  must  be  the  rightmost  node  of  the  level,  and 
whose  parent  must  also  be  a  pending  judgment. 

Next  we  define  transitions,  based  on  the  rules  of  the  natural  semantics,  that 
describe  how  one  partial  derivation  tree  can  be  transformed  into  another. 
Suppose  that  there  is  an  instance  of  an  evaluation  rule  that  has  the  form 

J\  J 2  ...  Jn 

H  b  e  =>  v,  /i' 


where  each  hypothesis  is  either  an  evaluation  judgment  Hi  b  e*  =>■  Vi,  or 
else  a  boolean  condition  R. 

The  transformations  resulting  from  this  rule  are  defined  as  follows: 

Suppose  that  a  partial  derivation  tree  T  contains  a  node  N  labeled  with  the 
pending  judgment  /i  b  e  =>?  and  that  the  children  of  N  are  labeled  with 
the  complete  judgments  J\,  J2, . . . ,  Jk  where  0  <  A;. 

-  Suppose  k  <  n.  Then  if  Jk+1  is  of  the  form  pk+i  ^  ek+ 1  =>  vk+ i,/4+ii  we 
can  transform  T  by  adding  another  child  to  Ah  labeled  with  the  pending 
judgment  pk+\  b  ek+i  =>?.  And  if  Jk+ 1  is  a  boolean  condition  Bk+ 1  that 
is  true,  we  can  transform  T  by  adding  another  child  to  N,  labeled  with 

Bk+ 1- 

-  Now  suppose  A:  =  n.  Then  we  can  transform  T  by  replacing  the  label  on 
N  with  the  complete  judgement  //  be=HJ,  ///. 

We  write  T  — >  T'  if  partial  derivation  tree  T  can  be  transformed  in  one  step 
to  Th  As  usual,  — >*  denotes  the  reflexive,  transitive  closure  of  — >. 

Remark  10  We  remark  that,  in  the  case  of  Polymorphic  C,  the  transforma¬ 
tion  relation  thus  defined  is  almost  deterministic.  In  particular,  although  there 
are  two  evaluation  rules  for  if  (ei)  {e2}  else  {e3}  and  while  (ei)  {e2}, 
there  is  no  ambiguity,  since  we  need  not  choose  which  rule  is  being  applied 
until  after  the  guard  e\  has  been  evaluated.  The  only  nondeterminism  in  the 
transformation  relation  is  in  rules  (bindvar)  and  (bindarr).  The  second  hy¬ 
pothesis  of  both  rules  is  (?',  0)  ^  dom(fi i),  and  here  metavariable  i  is  not  bound 
deterministically.  But,  of  course,  this  nondeterministic  choice  of  an  address  for 
a  newly-allocated  variable  or  array  is  of  no  importance.  □ 

A  key  property  of  — >  is  that  it  always  transforms  a  partial  derivation  tree 
into  another  partial  derivation  tree: 

Lemma  11  If  T  is  a  partial  derivation  tree  and  T  — »  T' ,  then  T'  is  also  a 
partial  derivation  tree. 
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PROOF.  Straightforward.  □ 


The  transformation  rules  give  us  the  desired  notion  of  program  execution:  to 
execute  e  in  memory  //,,  we  start  with  the  tree  T0  which  consists  of  a  single 
root  node  labeled  with  the  pending  judgment  //  b  e  =>?,  and  then  we  apply 
the  transformations,  generating  a  sequence  of  partial  derivation  trees: 

Tq  — »  Ti  — )•  T2  — >  T3  — »  •  •  • 


More  precisely,  we  define  an  execution  of  program  e  in  memory  //  to  be  a 
possibly  infinite  sequence  of  partial  derivation  trees  T0,Ti,T2,  . . .  such  that 

-  Tq  is  a  one-node  tree  labeled  with  //,  b  e  =>?, 

-  for  all  i  0,  Ti  — ^  (unless  X)  is  the  last  tree  in  the  sequence),  and 

-  if  the  sequence  has  a  last  tree  Tn,  then  there  is  no  tree  T  such  that  Tn  — >  T. 

Note  that  there  are  three  possible  outcomes  to  an  execution: 

(i)  The  sequence  ends  with  a  complete  derivation  tree.  This  is  a  successful 
execution. 

(ii)  The  sequence  is  infinite.  This  is  a  nonterminating  execution. 

(iii)  The  sequence  ends  with  a  tree  Tn  that  contains  a  pending  judgment  but 
has  no  successor.  This  is  an  aborted  execution. 

Our  Type  Soundness  theorem  will  show  that,  for  well-typed  programs,  aborted 
execution  can  arise  only  from  one  of  a  specific  set  of  errors. 

But  first,  we  argue  that  our  notion  of  execution  is  correct.  Let  us  write  [J] 
to  denote  the  one-node  tree  labeled  with  J.  The  soundness  of  our  notion  of 
execution  is  given  by  the  following  lemma. 

Lemma  12  If  [//,  b  e  =>?]  — >*  T,  where  T  contains  no  pending  judgments, 
then  T  is  a  complete  derivation  tree  for  a  judgment  of  the  form  p  b  e  =>  v,  p! . 


PROOF.  Bv  Lemma  11,  T  is  a  partial  derivation  tree.  So,  since  T  contains 
no  pending  judgments,  T  is  a  complete  derivation  tree  for  the  judgment  that 
labels  its  root.  And  this  judgment  must  be  of  the  form  p b  e  =>  v,  ///,  because 
the  initial  tree  has  a  root  labeled  with  p  b  e  =>?  and  (as  can  be  seen  by 
inspecting  the  definition  of  — >)  the  only  transformation  that  changes  the 
label  on  a  node  changes  a  label  of  the  form  //  b  e  =>?  to  a  label  of  the  form 
p  b  e  =>  v,  p! .  □ 
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Next  we  show  that  our  notion  of  execution  is  complete: 


Lemma  13  If  //  b  e  =>  v,  ///  and  T  is  a  complete  derivation  tree  for  /r  b  e  => 
u,  /j! ,  then  [//  b  e  =>?]  — >*  T. 


PROOF.  By  induction  on  the  structure  of  the  derivation  of  //  be=>  u,  □ 

Remark  14  This  lemma  shows  that  if  //,  b  e  y  v ,  //,',  then  there  is  a  success¬ 
ful  execution  of  e  in  (i.  But  it  does  not  show  that  every  execution  of  e  in  //  is 
successful.  With  an  arbitrary  natural  semantics,  this  need  not  be  so.  For  ex¬ 
ample,  in  a  language  with  a  nondeterministic  choice  operator,  some  executions 
of  e  in  p  may  be  successful,  others  may  be  nonterminating,  and  others  may 
abort.  But  in  Polymorphic  C,  since  — >  is  essentially  deterministic,  a  stronger 
result  should  hold.  □ 

Now  that  we  have  a  notion  of  program  execution,  we  again  turn  to  Poly¬ 
morphic  C  and  consider  what  we  can  say  about  the  executions  of  well-typed 
Polymorphic  C  programs. 

Definition  15  A  pending  judgment  /i  b  e  =>?  is  well  typed  iff  there  exist  mi 
address  typing  X  and  a  type  r  such  that  :  X  and  A;  0  b  e  :  r.  Also,  a  partial 
derivation  tree  T  is  well  typed  iff  every  pending  judgment  in  it  is  well  typed. 

Roughly  speaking,  the  combination  of  the  Type  Preservation  theorem  and  the 
Correct  Forms  lemma  (Lemma  2)  allows  us  to  characterize  the  forms  of  expres¬ 
sions  that  will  be  encountered  during  the  execution  of  a  well-typed  program. 
This  allows  us  to  characterize  what  can  go  wrong  during  the  execution.  Here 
is  the  key  type  soundness  result: 

Theorem  16  (Progress)  Let  T  be  a  well-typed  partial  derivation  tree  that 
contains  at  least  one  pending  judgment.  If  T  — »  T' ,  then  T'  is  well  typed. 
Furthermore,  there  exists  T'  such  that  T  — >  T' ,  unless  T  contains  one  of  the 
following  errors: 

El.  A  read  or  ivrite  to  a  dead  address. 

E2.  A  read  or  write  to  an  address  with  an  invalid  offset. 

E3.  A  read  of  an  uninitialized  address. 

Ej.  A  declaration  of  mi  array  of  size  0  or  less. 


PROOF.  Let  N  be  the  uppermost  node  in  T  that  is  labeled  with  a  pending- 
judgment,  say  //  b  e  =>?.  Then  any  transformation  on  T  must  occur  at  this 
node.  We  just  consider  all  possible  forms  of  expression  e.  Here  we  just  give 
the  case  ei=C2;  the  other  cases  are  quite  similar. 
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Since  T  is  well  typed,  the  pending  judgment  //  b  ei=e2  =>?  is  well  typed,  and 
so  there  exist  A  and  r  such  that  //  :  A  and  A;  0  b  ei=e2  :  r.  The  latter  typing- 
must  be  by  (ASSIGN): 


A;  0  b  ei  :  t  var 
A;  0  h  e2  :  r 

A;  0  h  ei=e2  :  r 


By  the  Correct  Forms  lemma,  e,\  must  be  of  the  form  ((?'.  j),  1)  or  else  of  the 
form  *ej.  So,  simplifying  notation  a  bit,  the  pending  judgment  that  labels  N 
has  the  form  //  b  (a,  l)=e  =b?  or  //  b  *ei=e2  =>?.  We  consider  these  two  cases 
in  turn. 

If  the  label  of  N  is  //  b  (a,  l)=e  =>?,  where  fi  :  A  and  A;  0  h  (ft,  1  )=e  :  r,  then 
the  typing  must  end  with  (ASSIGN): 

A;  0  b  (ft,  1)  :  r  var 
A;  0  b  e  :  r 

A;  0  b  (ft, l)=e  :  r 


So  by  (var),  ft  is  of  the  form  (?',  j),  where  A(i)  =  r. 

Now,  if  N  has  no  children,  then  (using  rule  (update)),  we  can  transform  T 
by  adding  to  N  a  new  child,  labeled  with  the  pending  judgment  ^  b  e  =>?. 
Furthermore,  this  is  the  only  possible  transformation,  and  since  A;  0  b  e  :  r, 
this  new  pending  judgment  is  well  typed. 

If  N  has  exactly  one  child,  then  by  condition  (ii)  of  the  definition  of  partial 
derivation  tree  and  the  fact  that  N  is  the  uppermost  node  labeled  with  a 
pending  judgment,  it  must  be  that  the  child  of  N  is  labeled  with  a  judgment 
of  the  form  //  b  e  =>  %  n'.  In  this  case,  we  may  transform  T  by  adding  a  new 
child  to  N  labeled  with  the  boolean  condition 

o  G  dom(n')  and  ///(ft)  ^  dead 


provided  that  this  condition  is  true. 

Now,  by  the  Type  Preservation  theorem,  there  exists  A'  such  that  A  C  A', 
///  :  A7,  and  A';0  b  »  :  r.  Hence  \'{i)  =  r,  and  so  (iO)  G  dom( fi').  So  if 
(i,j)  dom(^i'),  then  T  contains  error  E2,  a  write  to  an  address  with  an 
invalid  offset  j.  And  if  =  dead,  then  T  contains  error  El ,  a  write  to 

a  dead  address.  Hence  we  can  transform  T  unless  it  contains  error  E2  or  El. 
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Finally,  if  N  has  two  children,  then  they  must  be  labeled  with  the  hypotheses 
of  rule  (update),  and  so  we  can  transform  T  by  replacing  the  label  of  N  with 
p  b  (a,  l)=e  =4>  v,  fi'[a  :  =  t]. 

If  the  label  of  N  is  //  b  *ei=e2  =>?,  where  /i  :  A  and  A;  0  b  *ei=e2  :  r,  then  the 
typing  must  end  with  (l-val)  followed  by  (ASSIGN): 

A;  0  b  e\  :  r  ptr 

A;  0  b  *e\  :  r  war 
A;  0  b  e2  :  r 

A; 0  b  *ei=e2  :  r 


Now,  if  Ar  has  no  children,  then  the  only  applicable  transformation  (using  rule 
(update))  is  to  add  to  N  a  new  child,  labeled  with  the  pending  judgment 
//,  b  ei  =>?.  Since  A;  0  b  ei  :  r  ptr,  this  new  pending  judgment  is  well  typed. 

If  N  has  exactly  one  child,  then  by  condition  (ii)  of  the  definition  of  partial 
derivation  tree  and  the  fact  that  N  is  the  uppermost  node  labeled  with  a 
pending  judgment,  it  must  be  that  the  child  of  N  is  labeled  with  a  judgment 
of  the  form  //  b  e\  =4>  Wi,  ji\. 

By  the  Type  Preservation  theorem,  there  exists  Ai  such  that  A  C  Ai,  ji\  :  Ai, 
and  Ai;0  b  v\  :  t  ptr.  So  by  the  Correct  Form  lemma,  V\  is  of  the  form 
((?',j),  0).  Hence,  we  may  transform  T  by  adding  a  new  child  to  N  labeled 
with  the  boolean  condition 


wi  is  of  the  form  (a,  0), 


since  this  is  guaranteed  to  be  true.  Also,  by  (ptr),  Ai (/)  =  r. 

If  N  has  two  children,  then  we  can  transform  T  by  adding  a  new  child  labeled 
with  the  pending  judgment  ji\  b  e2  =>•?.  By  the  Superfluousness  Lemma, 
A| :  0  b  e2  :  r,  so  this  pending  judgment  is  well  typed. 

If  N  has  three  children,  then  the  third  child  of  N  must  be  labeled  with  a 
judgment  of  the  form  // 1  b  e2  =>  v ,^2.  In  this  case,  we  may  transform  T  by 
adding  a  new  child  to  N  labeled  with  the  boolean  condition 

a  G  dom(p2 )  and  //2(a)  ^  dead 


provided  that  this  condition  is  true. 

As  before,  by  the  Type  Preservation  theorem,  there  exists  X'  such  that  Ai  C  A', 
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Ih  :  A',  and  A 0  b  v  :  r.  Hence  A'(i)  =  r,  and  so  (/,  0)  G  dom(^2).  So  if 
(?',  j)  fL  dom(^2),  then  T  contains  error  fAA  a  write  to  an  address  with  an 
invalid  offset  j.  And  if  /r2((?',  j))  =  dead,  then  T  contains  error  El,  a  write  to 
a  dead  address.  Hence  we  can  transform  T  unless  it  contains  error  E2  or  El. 

Finally,  if  N  has  four  children,  then  they  must  be  labeled  with  the  hypotheses 
of  rule  (update),  and  so  we  can  transform  T  by  replacing  the  label  of  N  with 
//  b  *ei=e2  =>  v,  fi2[a  :=  v].  □ 


The  Progress  theorem  gives  our  Type  Soundness  result  as  a  simple  corollary: 

Corollary  17  (Type  Soundness)  //A;0  b  e  :  r  and  /a  :  X,  then  any  execu¬ 
tion  of  e  in  n  either 

(i)  succeeds, 

(ii)  does  'not  terminate,  or 

(in)  aborts  due  to  one  of  the  errors  El,  E2,  E3,  or  Ef. 


PROOF.  Let  T0  — )•  — )►  T2  — >  ■  ■  ■  be  an  execution  of  e  in  //,.  Then 

To  =  [n  b  e  =>?],  which  is  well  typed  by  assumption.  So,  by  the  Progress 
theorem,  every  T»  is  well  typed,  and  furthermore,  if  T)  contains  a  pending 
judgment,  then  it  has  a  successor  unless  it  contains  one  of  the  errors  El,  E2, 
E3,  or  Ef.  So,  if  the  execution  is  finite,  it  either  ends  with  a  complete  derivation 
tree  or  with  a  tree  containing  one  of  the  errors  El,  E2 ,  E3,  or  Ef.  □ 


6  Discussion 


One  of  the  most  desirable  properties  of  a  programming  language  implemen¬ 
tation  is  that  it  guarantee  the  safe  execution  of  programs.  This  means  that  a 
program’s  execution  is  always  faithful  to  the  language’s  semantics,  even  if  the 
program  is  erroneous.  C  is,  of  course,  a  notoriously  unsafe  language:  in  typical 
implementations,  pointer  errors  can  cause  a  running  C  program  to  overwrite 
its  runtime  stack,  resulting  in  arbitrarily  bizarre  behavior.  Sometimes  this 
results  in  a  “Segmentation  fault — core  dumped”  message  (though  this  may 
occur  far  after  the  original  error);  worse,  at  other  times  the  program  appears 
to  run  successfully,  even  though  the  results  are  entirely  invalid. 

Three  techniques  can  be  used  to  provide  safe  execution: 

(i)  The  language  can  be  designed  so  that  some  errors  are  impossible.  For  ex¬ 
ample,  a  language  can  define  default  initializations  for  variables,  thereby 
preventing  uninitialized  variable  errors. 
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(ii)  The  language  can  perform  compile-time  checks,  such  as  type  checks,  to 
guard  against  other  errors. 

(iii)  Finally,  runtime  checks  can  be  used  to  catch  other  errors. 

In  the  case  of  Polymorphic  C,  the  Type  Soundness  theorem  (Corollary  17) 
specifies  exactly  what  runtime  checks  are  needed  to  guarantee  safe  execution. 
The  trouble  is,  except  for  error  E4  (declaring  an  array  of  size  0  or  less),  typical 
C  implementations  do  not  make  these  checks.  What  would  we  expect,  then, 
of  implementations  of  Polymorphic  C?  Well,  it  is  actually  not  too  difficult  to 
check  for  error  E2  (reading  or  writing  an  address  with  an  invalid  offset) — for 
each  pointer,  we  must  maintain  at  runtime  the  range  of  permissible  offsets. 
And  error  E3  (reading  an  uninitialized  address)  can  also  be  checked  fairly 
efficiently,  by  initializing  array  cells  with  a  special  uninit  value.  That  leaves 
only  error  El  (reading  or  writing  a  dead  address).  This,  of  course,  is  very 
difficult  to  check  efficiently.  In  our  natural  semantics,  we  make  this  check 
possible  by  never  reusing  any  cells! 

Hence  we  reach  a  point  of  trade-offs.  We  can  directly  implement  our  natural 
semantics,  getting  a  safe  but  inefficient  “debugging”  implementation  of  Poly¬ 
morphic  C.  Or  we  can  follow  usual  C  practice  and  build  a  stack-based  imple¬ 
mentation  that  leaves  errors  El  (and  perhaps  E2  and  E3  as  well)  unchecked, 
achieving  efficiency  at  the  expense  of  safety.  4  In  this  case,  the  Type  Soundness 
theorem  at  least  tells  us  what  kinds  of  errors  we  need  to  look  for  in  debugging 
our  programs.  As  a  final  alternative,  we  can  change  the  semantics  of  Poly¬ 
morphic  C  by  giving  cells  unbounded  lifetimes  (thereby  necessitating  garbage 
collection),  as  was  done  in  the  design  of  Java  [1]. 


7  Conclusion 


Advanced  polymorphic  type  systems  have  come  to  play  a  central  role  in  the 
world  of  functional  programming,  but  so  far  have  had  little  impact  on  tradi¬ 
tional  imperative  programming.  We  assert  that  an  ML-style  polymorphic  type 
system  can  be  applied  fruitfully  to  a  “real-world”  language  like  C,  bringing  to 
it  both  the  expressiveness  of  polymorphism  as  well  as  a  rigorous  characteriza¬ 
tion  of  the  behavior  of  well-typed  programs. 

Future  work  on  Polymorphic  C  includes  the  development  of  efficient  imple¬ 
mentations  of  polymorphism  (perhaps  using  the  work  of  [13,18,10])  and  the 
extension  of  the  language  to  include  other  features  of  C,  especially  structures. 


4  More  precisely,  allocating  variables  and  arrays  on  a  stack  in  Polymorphic  C  (or  in 
any  language  with  &  or  that  unifies  arrays  and  pointers)  causes  the  type  preservation 
property  to  fail. 
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